1. Field of Invention
The invention relates generally to computer systems. More particularly, methods and apparatus for providing highly interactive, robust, and scalable on-demand network application delivery and execution capabilities in a distributed computer network are disclosed.
2. Description of Relevant Art
Generally speaking, a browser is an application program that provides a way to look at and interact with information on distributed computer networks such as the Internet. In particular, a Web browser is a client program that uses the Hypertext Transfer Protocol (HTTP) to make requests of Web servers throughout the Internet on behalf of the browser user. One of the most recent uses of browsers is in the realm of electronic (e-) commerce in which any number of client side users (i.e. xe2x80x9ce-customersxe2x80x9d) interact in a real time basis with any number of server side processors (i.e., xe2x80x9ce-sellersxe2x80x9d) over the Internet. In order to transact business in a Web-based environment, browsers typically execute Web commerce applications specifically designed to facilitate e-commerce transactions such as requesting quotes, selecting options and assembling components into complex bundles, and placing orders.
In this regard, successful Web commerce applications must be capable of automating a customer through the entire buying cycle, from initial inspection to final purchase and shipping, in addition to providing the customer all relevant information required to make a buying decision and providing customer guidance. As the complexity of the buying cycle and/or the purchases themselves increasesxe2x80x94for instance, from buying office supplies to buying mainframe computersxe2x80x94a general purpose Web commerce application must scale its ability to manage this complexity. In order to accomplish this, a general purpose Web commerce application must be: 1) fast loading and highly responsive in xe2x80x9cclick over clickxe2x80x9d type scenarios in order to support highly interactive customer sessions such that a buyer can input any and all relevant information quickly and with apparently little or no delay in application response; 2) powerful in its ability to process relevant data from a broad range of possible choices, configurations, and problem domains quicklyxe2x80x94in other words, a general purpose Web commerce application should have the flexibility and computational power of a conventional programming language; 3) the application must be robust in that it can run on a wide variety of client machines while maintaining greater than 99% up time, and finally; 4) the Web commerce application must be highly scalable given the unpredictable and potentially large number of buyers who may simultaneously access the application online.
Conventional attempts to construct general purpose e-commerce application include embedded client-side applications: Java applets, or ActiveX controls. As a class, these are generally small programs that can be sent along with a Web page to a browser to execute interactive animations, immediate calculations, or other simple tasks using the computing resources of the client without having to send a request back for processing on the server. As an example, as shown in FIG. 1, a distributed computer system 100 includes a client computer 102 that is coupled to a server (host) computer 104. The computer 102 includes a browser application 106 that, in turn, includes a requested Web page 108 having an applet 110 embedded therein capable of performing various tasks. In most situations, the applet 110 is executed by a Java Virtual Machine (JVM) 112 that in this example is also resident in the browser 106.
In order for the JVM 112 to execute the applet 110 the applet""s requisite component files (such as xe2x80x9c.class filesxe2x80x9d, images and sounds), represented by files 114-118, must be downloaded from the server 104 to the JVM 112. Typically the server 104 is part of a distributed network of computers, such as the Internet, or in some cases could be part of an intranet. In any case, the files 114-118 that are required for the JVM 112 to run the applet 110 include Java class files as well as resource files that are used to support the execution of the applet 110. Such class files include a main class file, main class 114, that is used by the JVM 112 as an entry point for execution of the applet 110. The server 104 also stores other class files such as b.class 116 that are used by the JVM 112 in the furtherance of executing the applet 110. Various image and sound components used in the execution of the applet 110 are stored in resource files such as c.image 118.
In order for the JVM 112 to execute the applet 110, it may be required to download some of the class and resource files as needed. This is typically accomplished by sending a file request that takes the form of an HTTP request to the server 104 which responds by providing the requested file. By way of example, the JVM 112 issues a request to retrieve the main class file main.class 114 to which the server 104 responds by sending (i.e., downloading) the requested file (i.e., main.class 114). This request/response procedure is followed for every file for which the JVM 112 requires to execute the applet 110.
As can be readily appreciated, the Java applet approach is not highly interactive since in general it may require a substantial amount of time to download the JVM and will require time to download needed class files before the applet can even initiate. In addition, no particular provision is made to segment application specific applet code as problem complexity grows. Thus, the larger and more complex the e-commerce problem, the larger and slower the initial download prior to user interaction. Finally, since there are a large variety of JVMs and class files available, and since Java is unstable on many client machines, making a Java based applet robust across all or even most users would require many hundreds of thousands of bytes to be downloaded across the Internet. These large data transfers would be counterproductive to producing the highly interactive experience desired by the e-customer. Therefore, in order to improve the interactivity of the applet (by reducing the size of the data transfers), the robustness of the applet would be adversely affected since some platforms would not be effectively serviced.
Another conventional approach to delivering general purpose e-commerce applications is referred to as server side processing. In server side processing, all application processing is performed on the server and does not use the computer resources of the client. In this way, the problems related to initial load time and robustness are solved. However, this comes at the cost of interactivity since the servers are physically separated from the clients in a distributed network of computers such as the Internet. Even with the advent of broadband access, the performance of a server side application will always be generally slower than an equivalent client side application simply because each interaction, processing, and response cycle requires the physical transfer of requests across a network that is subject to congestion, transfer failure, and communication overhead.
In addition to speed considerations, it is difficult to find a general solution to scaling the server side facility since every time a new user is added, additional processing capabilities must be provided by the server. In the general access environment of the Internet, unpredictable end-user demand can cause sudden usage spikes, or can simply grow to overwhelm available server resources. Finally, since thousands of even millions of clients share the same network of server side processing resources, errors in or changes to the application run the very real risk of simultaneously shutting out all users, causing potentially large losses of time and revenues. Generally, a client side solution can avoid these problems by distributing processing out to each client""s machine.
Finally, it is in principle possible to develop and deliver to each end user""s machine code that is custom written for the particular combination of browser, platform, and e-commerce application. However, this is not a general purpose solution, as it cannot realistically be expected that the many millions of e-commerce applications running on their respective browsers can be truly customized within a reasonable length of time.
In addition to the above described shortcomings of the conventional approaches to delivering general purpose e-commerce application, asynchronous loading of data and code segments requires that any generic application engine must provide a generic layer for management of thread states and signaling of initiation and termination.
Since conventional browsers do not provide the requisite thread management routines, therefore, what is desired are techniques for providing reentrant threading in an asynchronous environment, such as that of a browser.
Techniques for managing multiple threads in an asynchronous environment, such as a browser, are described. In one embodiment of the invention, a method is disclosed. An event thread is instantiated in response to a user event by a shell event handler block that provides shell functions for a user event. Once the event thread as been instantiated, the event thread is managed by a generic thread manager block that provides a plurality of multithread management functions for the shell event handler. When required, the event thread is blocked or unblocked by a blocking system that is arranged to block and unblock threads.
In another embodiment, a computer program product for managing multiple threads in a browser program executing on a client platform is disclosed. The computer program product includes computer code that instantiates an event thread in response to a user event by a shell event handler block that provides shell functions for a user event and computer code that manages the event thread by a generic thread manager block that provides a plurality of multithread management functions for the shell event handler. The computer program product further includes computer code that blocks and unblocks the event thread when required. In a preferred embodiment, the computer code is stored in a computer readable medium.
In yet another embodiment, an apparatus for managing multiple threads in a browser program executing on a client platform is disclosed. The apparatus includes software means for instantiating an event thread in response to a user event by a shell event handler block that provides shell functions for a user event and software means for managing the event thread by a generic thread manager block that provides a plurality of multithread management functions for the shell event handler. The apparatus also includes software means for blocking and unblocking the event thread when required.